According to the Open Mobile Alliance (OMA) Architecture Document “XML Document Management Architecture” (currently at OMA-AD-XDM-V2—0-20070724-C; XML is an abbreviation for “Extensible Markup Language”), the XML Document Management (XDM) enabler defines a common mechanism that makes user-specific service-related information accessible to the service enablers that need them. Such information is expected to be stored in the network where it can be located, accessed and manipulated (e.g. created, changed, deleted, etc.). XDM specifies how such information will be defined in well-structured XML documents, as well as the common protocol for access and manipulation of such XML documents.
The XDM Specification [“XML Document Management (XDM) Specification”, Version 2.0, Open Mobile Alliance, OMA-TS-XDM_Core-V2—0, URL: http://www.openmobilealliance.org/] defines the features of the XDM enabler, which include the following:                The common protocol, XML Configuration Access Protocol (XCAP) [IETF RFC 4825 “The Extensible Markup Language (XML) Configuration Access protocol (XCAP)”, J. Rosenberg, May 2007, URL: http://www.ietf.org/rfc/rfc4825.txt], by which Principals can store and manipulate their service-related data, stored in a network as XML documents.        The SIP (Session Initiation Protocol) subscription/notification mechanism by which Principals can be notified of changes to such documents.        The mechanism by which Principals can search service-related data stored in a network as XML documents using limited XQuery [W3C Recommendation “XQuery 1.0: An XML Query Language”, Scott Boag et al, Jan. 23 2007, World Wide Web Consortium (W3C), URL: http://www.w3.org/TR/xquery].        
Documents accessed and manipulated via XCAP are stored in logical repositories in the network, called XDMS (XDM Server). Each repository may be associated with a functional entity which uses its data to perform its functions.
Each XML document stored in an XDMS is described as an XCAP Application Usage, which enables applications to use the document via XCAP. The XDM enabler describes Application Usages which can be reused by multiple enablers and are stored in the Shared XDMSs, of which there are four types: Shared List XDMS, Shared Group XDMS, Shared Policy XDMS and Shared Profile XDMS. The documents supported by these XDMSs are as follows:                URI List and Group Usage List documents in the Shared List XDMS [“Shared List XDM Specification”, Version 2.0, Open Mobile Alliance, OMA-TS-XDM_Shared-V2—0, URL: http://www.openmobilealliance.org/];        Group document in the Shared Group XDMS [“Shared Group XDM Specification”, Version 1.0, Open Mobile Alliance, OMA-TS-XDM_Shared_Group-V1—0, URL: http://www.openmobilealliance.org/];        User access policy document in the Shared Policy XDMS [“Shared Policy XDM Specification”, Version 1.0, Open Mobile Alliance, OMA-TS-XDM_Shared_Policy-V1—0, URL: http://www.openmobilealliance.org/]; and        
User Profile document in the Shared Profile XDMS [“Shared Profile XDM Specification”, Version 1.0, Open Mobile Alliance, OMA-TS-XDM_Shared_Profile-V1—0, URL: http://www.openmobilealliance.org/].
In addition to the above documents, the XDM Enabler also defines the Extended Group Advertisement.
Due to the reusable nature of the XDM enabler, there will be interactions with other service enablers, and therefore, the architectural design of the XDM enabler accommodates the needs of those enablers.
It can be seen that the XML Document Manager (XDM) provides an architecture for managing service specific data. The XML Document Management defines a common mechanism that makes user-specific service-related information accessible to the service enablers that need them. The service-specific information is expressed and exchanged by means of XML documents, and this information is stored in the network where it can be located, accessed and manipulated (created, changed, deleted, etc.). The network entity assumed responsible for storing and manipulation of such information is the XDM Server (XDMS).
FIG. 1 of the accompanying drawings illustrates some of the network entities defined in the above-referenced OMA Architecture Document. In FIG. 1, two XDM Clients 2-1 and 2-2 are in communication with respective different XDM Servers 6-1 and 6-2 via an Aggregation Proxy 4. The XDM Clients 2-1 and 2-2 are client entities that provide access to the various XDMS features. They provide an end user with the possibility to create, modify or delete an XML document, and by that create, modify or delete service specific data. The Aggregation Proxy 4 is the contact point for the XDM Clients 2-1 and 2-2 to access XML documents stored in any XDM Server; the Aggregation Proxy 4 performs functions like authentication or routing of requests. The XDM Servers 6-1 and 6-2 hold the service specific data, and implement the procedures to create, modify or delete such data.
FIG. 2 shows in more detail the currently-proposed XML Document Management Architecture solution, this Figure being extracted from the OMA-AD-XDM-V2—0-20070724-C document. Parts shown in FIG. 2 will now be described.
According to OMA-AD-XDM-V2—0-20070724-C, the Aggregation Proxy of FIG. 2 is the contact point for the XDMC (XDM Client) to access XML documents stored in any XDMS. The Aggregation Proxy performs the following functions: (a) performs authentication of the XDMC; (b) routes individual XCAP requests to the correct XDMS or Aggregation Proxy of Remote Network; (c) routes individual Search requests to the Search Proxy; (d) optionally performs compression/decompression; and (e) supports secure data transfer between the Aggregation Proxy and the Aggregation Proxy of Remote Network, using TLS or other means.
The Search Proxy of FIG. 2 is the contact point for the XDMC to search information from XML documents stored in any XDMS. The Search Proxy performs the following functions: (a) forwards search requests to the XDMS, also to the Aggregation Proxy of Remote Networks when needed; (b) receives responses from the XDMS, and from the Aggregation Proxy of Remote Networks when needed; (c) combines results from the XDMS, and also from the Aggregation Proxy of Remote Networks before sending responses to the XDMC; (d) sends search responses to the XDMC; and (e) supports secure data transfer between Search Proxy and the Aggregation Proxy of Remote Network, using TLS or other means.
The Aggregation Proxy of Remote Network of FIG. 2 is the contact point for a trusted network to access XML documents stored in any XDMS of the remote network. The Aggregation Proxy of Remote Network performs the following functions: (a) performs authorization of the trusted network; (b) routes individual XCAP requests to the correct XDMS; (c) routes individual search requests to the Search Proxy; (d) optionally performs compression/decompression; (e) supports secure data transfer between the Aggregation Proxy of Remote Network and the trusted network, using TLS or other means.
The XDM-8 reference point of FIG. 2 is between the Aggregation Proxy and the Aggregation Proxy of Remote Network. The protocol for the XDM-8 reference point is XCAP. The XDM-8 reference point provides the following functions: (a) secure data transfer between the Aggregation Proxy and the Aggregation Proxy of Remote Network; and (b) forwarding of requests/responses to the Aggregation Proxy of Remote Network.
The XDM-9 reference point of FIG. 2 is between the Search Proxy and the
Aggregation Proxy of Remote Network. The protocol for the XDM-9 reference point is “Limited XQuery over HTTP”. The XDM-9 reference point provides the following functions: (a) secure data transfer between the Search Proxy and the Aggregation Proxy of Remote Network; (b) forwarding of search requests/responses between the Search Proxy and the Aggregation Proxy of Remote Network.
In this OMA defined XDM solution it would be possible to fetch XCAP documents and search for information in XCAP documents in another operator's domain using an NNI (Network-to-Network Interface).
The traffic to the remote network is routed via an Aggregation Proxy entity of the remote network (Aggregation Proxy of Remote Network). The protocol used is HTTP over some secure transport, such as for example TLS (Transport Layer Security). The requesting network requires some kind of service agreement with the remote network in order to be accepted by the remote network.
The OMA defined solution for NNI between domains specifies that the address to the Aggregation Proxy of Remote Network is inserted using a configuration in the servers that contact the Aggregation Proxy of Remote Network.
The solution also assumes that other parameters like the XCAP Root URI of the remote domain is known by the calling servers.
As the name of an Aggregation Proxy of Remote Network may be changed by the service provider, this means that all other service providers that have a service agreement with this operator also must change their configuration.
There also exist situations when the service provider for a domain is changed from one service provider to another service provider. One example is when a user has their own domain and has an agreement with one service provider to host the XDM and SIP traffic for this domain and wants to change service provider.
It is desirable to address the above-mentioned issues.